home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000055_owner-urn-ietf _Wed Mar 26 16:04:18 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  8KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id QAA02935
  3.     for urn-ietf-out; Wed, 26 Mar 1997 16:04:18 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id QAA02930
  6.     for <urn-ietf@services.bunyip.com>; Wed, 26 Mar 1997 16:04:13 -0500 (EST)
  7. Received: from nix.swip.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA01506  (mail destined for urn-ietf@services.bunyip.com); Wed, 26 Mar 97 16:04:08 -0500
  9. Received: from localhost (paf@localhost) 
  10.           by nix.swip.net (8.8.2/8.8.2) with SMTP 
  11.           id WAA04439; 
  12.           Wed, 26 Mar 1997 22:04:04 +0100 (MET)
  13. Date: Wed, 26 Mar 1997 22:04:04 +0100 (MET)
  14. From: Patrik Faltstrom <paf@swip.net>
  15. To: Internet-Drafts@ietf.org
  16. Cc: urn-ietf@bunyip.com, Renato Iannella <renato@dstc.edu.au>,
  17.         Leslie Daigle <leslie@bunyip.com>
  18. Subject: [URN] draft-ietf-urn-nid-req-01.txt
  19. Message-Id: <Pine.SUN.3.95.970326220023.530E-100000@nix.swip.net>
  20. Mime-Version: 1.0
  21. Content-Type: TEXT/PLAIN; charset=US-ASCII
  22. Sender: owner-urn-ietf@Bunyip.Com
  23. Precedence: bulk
  24. Reply-To: Patrik Faltstrom <paf@swip.net>
  25. Errors-To: owner-urn-ietf@Bunyip.Com
  26.  
  27. INTERNET DRAFT                                             Renato Iannella
  28. draft-ietf-urn-nid-req-01.txt                                 DSTC Pty Ltd
  29. 25 March, 1997                                            Patrik Faltstrom
  30.                                                              Tele2/Swipnet
  31.  
  32.             Namespace Identifier Requirements for URN Services
  33.  
  34.  
  35.  
  36. Status of this Memo
  37. ===================
  38.  
  39.     This document is an Internet-Draft.  Internet-Drafts are working
  40.     documents of the Internet Engineering Task Force (IETF), its
  41.     areas, and its working groups.  Note that other groups may also
  42.     distribute working documents as Internet-Drafts.
  43.   
  44.     Internet-Drafts are draft documents valid for a maximum of six
  45.     months and may be updated, replaced, or obsoleted by other
  46.     documents at any time.  It is inappropriate to use Internet-
  47.     Drafts as reference material or to cite them other than as
  48.     `work in progress.'
  49.  
  50.     To learn the current status of any Internet-Draft, please check
  51.     the `1id-abstracts.txt' listing contained in the Internet-
  52.     Drafts Shadow Directories on ftp.is.co.za (Africa),
  53.     nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  54.     ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  55.  
  56.     This draft expires 25 September, 1997.
  57.  
  58.  
  59. Abstract:
  60. =========
  61.  
  62. Services that offer to resolve Uniform Resource Names implicitly
  63. require that they support a persistent and reliable service for an
  64. indeterminate length of time. This draft outlines the requirements for
  65. any such service that wishes to participate as a Namespace Identifier.
  66.  
  67.  
  68. Introduction:
  69. =============
  70.  
  71. The Uniform Resource Name (URN) Working Group has defined mechanisms
  72. for both the syntax [4] and resolution of URNs [1,2]. An framework
  73. for URN discovery systems has also been outlined [3]. This draft
  74. discusses and recommends the requirements for entities that wish
  75. to act as Namespace Identifiers (NIDs) within the URN system.
  76.  
  77. The URN syntax includes the NID which acts as the scoping
  78. indicator for the URN. The NID indicates which Namespace
  79. the URN belongs to and gives hints to the underlying resolution
  80. service.
  81.  
  82. Consider the following example URNs:
  83.  
  84.    urn:znet:metadata.net:dc
  85.    urn:buns:555555:annual-report
  86.    urn:hoptus:priv:555-ABCD
  87.  
  88.  
  89. The NIDs in these cases, "znet", "buns", and "hoptus" all
  90. act as top-level namespaces, and hence, must meet certain
  91. guidelines to ensure meeting all the URN requirements [5].
  92. In particular:
  93.    - Global Scope and Uniqueness
  94.    - Persistence
  95.    - Independence
  96.    - Resolution
  97.  
  98.  
  99. Requirements:
  100. =============
  101.  
  102. Given the four categories above, the requirements for each our
  103. now outlined.
  104.  
  105.  
  106.  Global Scope and Uniqueness.
  107.  
  108.   - The NID must be registered with IANA to ensure uniqueness and
  109.     demonstrating that it meets the requirements listed in this
  110.     document.
  111.   - A simple and limited character set should be imposed to 
  112.     support global access (as described in [4]).
  113.   - Rules on how the Namespace Specific String are allocated
  114.     must be documented.
  115.   - Definitions of terms like "equal" and "different" for resources
  116.     must be published.
  117.  
  118.  Persistence
  119.  
  120.   - The NID service providers must show that they intend to
  121.     support the service for an indefinite period of time.
  122.   - Support facilities must be described and how the service
  123.     intends to operate, including "disaster recovery"-like
  124.     operations.
  125.   - Demonstrated experience in managing an established namespace
  126.     system is essential.    
  127.   - One URN should never be reused for a different resource (where
  128.     "different" is defined as in previous paragraph by the namespace).
  129.     The URN should be persistent for all times, even though the
  130.     resource goes away.
  131.  
  132.  Independence
  133.  
  134.   - The NID service providers must also show any relationship
  135.     (both technical and administrative) that may impede on the
  136.     provision of the URN service.
  137.   - However, multi-party participation in the NID service is
  138.     an advantage.
  139.  
  140.  Resolution
  141.  
  142.   - The NID service providers must produce an RFC
  143.     describing the technical characteristics of the URN
  144.     resolution service, including security considerations.
  145.   - The NID service providers may elect not to have the
  146.     resolution service publically available.
  147.  
  148.  
  149. Example:
  150. =======
  151.  
  152. (1) urn:buns:555555:annual-report
  153.  
  154. This URN, in the namespace called "buns" is referring to the
  155. document named annual-report, in postscript format. 
  156.  
  157. At a later stage, that resource is replaced by a text version, which
  158. lacks the pictures, but that is ok, because the namespace has decided
  159. that postscript format documents and text documents are considered the
  160. same even though the figures doesn't exist in the textual version.
  161.  
  162. In the third stage, the report is removed, and replaced with a report
  163. for a different year. This new report gets a new URN because it is
  164. considered being a different document.
  165.  
  166. The old URN is never reused.
  167.  
  168. (2) urn:foo:bar:current-weather
  169.     urn:foo:bar:weather/19970325
  170.  
  171. These are two URNs referring at one stage to the same resource, i.e.
  172. on the 25th of March 1997. On the 26th of March 1997,
  173. urn:foo:bar:current-weather is referring to the same resource as
  174. urn:foo:bar:weather/19970326.
  175.  
  176. Conclusion:
  177. ===========
  178.  
  179. This draft has outlined the requirements for providers of
  180. NID services for URN systems. The objective is to maintain 
  181. a high persistence rate for URN services, and these requirements
  182. are aimed at ensuring a high level of service stability.
  183.  
  184.  
  185.  
  186. References:
  187. ===========
  188.  
  189. [1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
  190.     Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
  191.     February, 1997.
  192.  
  193. [2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
  194.     draft-ietf-urn-http-conv-01.txt, February 1997
  195.  
  196. [3] Karen R Sollins, "Requirements and a Framework for URN Resolution
  197.     Systems", draft-ietf-urn-req-frame-00.txt, November 1996
  198.  
  199. [4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997.
  200.  
  201. [5] Karen R Sollins & Larry Masinter, "Functional Requirements for
  202.     Uniform Resource Names", RFC1737, December 1994
  203.  
  204.  
  205. Security Considerations
  206. =======================
  207.  
  208. It is a requirement that it in the definitions of a namespace are
  209. included sections on security covering for example:
  210.  
  211.   + Spoofing of servers
  212.   + Verification of responses
  213.  
  214. Because a namespace can decide that a resolution service is not
  215. publically available, it is possible to use firewall installations and
  216. other traffic limiting constructions to diconnect the namespace from
  217. the global Internet.
  218.  
  219. Author Contact Information:
  220. ===========================
  221.  
  222. Renato Iannella
  223. DSTC Pty Ltd
  224. Gehrmann Labs, The Uni of Queensland
  225. AUSTRALIA, 4072
  226. voice:  +61 7 3365 4310
  227. fax:    +61 7 3365 4311
  228. email:  renato@dstc.edu.au
  229.  
  230.  
  231. Patrik Faltstrom
  232. Tele2/Swipnet
  233. Borgarfjordsgatan 16
  234. P.O. Box 62
  235. S-164 94 Kista
  236. SWEDEN
  237. voice:  +46-5626 4000
  238. fax:    +46-5626 4200
  239. email:  paf@swip.net
  240.  
  241.  
  242.